home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 91 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.1 KB  |  85 lines
  1. Path: fido.asd.sgi.com!austern
  2. From: Eugene Lazutkin <eugene@int.com>
  3. Newsgroups: comp.std.c++
  4. Subject: FW: Inherent C++ problem (for comp.std.c++)
  5. Date: 22 Jan 1996 10:13:43 PST
  6. Organization: -
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <01BAE8B0.C408A920@dino.int.com>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. X-Original-Date: Mon, 22 Jan 1996 10:02:39 -0600
  11. Encoding: 65 TEXT
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMQPT9Uy4NqrwXLNJAQHbywH/QpYbBmEmJxb8uOnYIBQPr0qxXo6cJxiz
  14.     mRlKsY+wjzF0T1JgfwXEA6DCIZN/pViRLXHAW4WRavV0EG5T4A5TZQ==
  15.     =x+7V
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. ----------
  19. From:     Max Motovilov[SMTP:max@int.com]
  20. Sent:     Monday, January 22, 1996 8:52 AM
  21. To:     'Eugene Lazutkin'
  22. Subject:     Re: Inherent C++ problem (for comp.std.c++)
  23.  
  24. > Well, a typical optimisation here would be to construct the temporary
  25. > inside op+ directly into the return value slot. The construction of 'c'
  26. > would likely pass the address of 'c' as the return value slot. Thus, with
  27. > suitable inlining, it becomes very efficient.
  28.  
  29. > And the current wording of the draft allows such optimisations --
  30. > effectively arbitrary copy constructor invocations can be eliminated if
  31. > either the copy or the original is never used again (as in this example).
  32.  
  33. This is exactly the kind of optimization that one would be expecting but it cannot
  34. possibly work, at least not with the non-inline copy constructors:
  35.  
  36. //****** Complex.h
  37.  
  38.     class    Complex
  39.     {
  40.     ............
  41.         Complex( const Complex& );
  42.     ............
  43.     };
  44.  
  45. //****** Complex.cpp
  46.  
  47.     int    stupid_global = 0;
  48.  
  49.     Complex::Complex( const Complex& c ) : re( c.re ), im( c.im )
  50.     {
  51.         stupid_global++;
  52.     }
  53.  
  54. Now, in the body of the method
  55.  
  56.     Complex    operator + ( const Complex& a, const Complex& b )
  57.     {
  58.         return Complex( a.re+b.re, a.im+b.im );
  59.     }
  60.  
  61. compiler has no way to know that copy constructor has a non-local side effect. 
  62. Otherwise the case is exactly like the one suitable for optimization, that is, source 
  63. object is never going to be used again. However the presence or absence of the 
  64. optimization results in a different program behavior.
  65.  
  66. As for the (2) to (3) transition by means of reserving the slot by the caller rather
  67. than the callee, the same concern applies. Standard doesn't require the compiler
  68. to behave one way or the other thus the improper dependance on the optional
  69. optimization may take place in the program. Since there is apparently no way to
  70. prohibit side effects in copy constructors (without compromizing certain consitency
  71. in the language) and it is unwise to impose any requirements on the way compilers
  72. implement object return by value it should probably be explicitly said in the standard
  73. that in certain cases invokation of the copy constructor (that is, method call!) is
  74. not guaranted by the implementation. It would be still bad for a consistent design,
  75. but at least unambiguous....
  76.  
  77. If the current wording is already supposed to provide for it, I suggest it Re:made more
  78. explicit in regard to this problem.
  79.  
  80. ...Max...
  81. ---
  82. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  83.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  84.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  85.